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REAL PARTY IN INTEREST 



The assignee of the above-referenced patent application, Oracle America, Inc. is the 
real party in interest. 
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RELATED APPEALS AND INTERFERENCES 

No other appeals or interferences are known to the undersigned Attorney for 
Appellant, or the Assignee Appellant, which will directly affect, or be directly affected by, 
have a bearing on the Board's decision in this pending Appeal. 
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STATUS OF CLAIMS 

Claims 10 to 18, 28 to 36, and 72 to 88 are pending. Claims 1 to 9, 19 to 27, and 37 to 
71 have been cancelled. Claims 10 to 18, 28 to 36, and 72 to 88 stand rejected in the Final 
Office Action dated February 18, 2010, and in the Advisory Action dated May 13, 2010. The 
rejections of Claims 10 to 18, 28 to 36 and 72 to 88 are hereby appealed. 
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STATUS OF AMENDMENTS 



All amendments to the claims presented by Appellant have been entered. 



Page 5 of 42 



Serial No. 10/687,459 

Notice of Appeal Entered: June 18, 2010 

Appeal Brief Filed: August 18, 2010 



SUMMARY OF CLAIMED SUBJECT MATTER 



A summary is provided below for each independent claim and for each dependent 
claim argued separately. 

CLAIM 10 

Claim 10 recites a method for digital content access control {Fig. 63}. Initially, the 
method determines, on a user device {6300, (Fig. 63); See also 5500, (Fig.55)}, a digital 
content specification and associated authenticated rights locker access request {6305, (Fig. 
63); Paragraph [0223], lines 4, 5 at pg. 114}. The associated authenticated rights locker 
access request was authenticated by a right locker provider for the rights locker. {Paragraph 
[0208], lines 2 to 4 at pg. 108, and Paragraph [0153], lines 6 to 13 at pgs. 82, 83.} 

The method sends, from the user device {6300, (Fig. 63)} to the rights locker provider 
for the rights locker {6335, (Fig. 63)} the authenticated rights locker access request and the 
digital content specification {6315, (Fig. 63); Paragraph [0223], lines 6 to 8at pgs. 1 14, 1 15}. 
Next, the method receives, on the user device from the rights locker provider, a new 
authenticated rights locker access request for the rights locker and a Web page with one or 
more clickable links in response to the sending, at least one of the one or more clickable links 
is associated with an authenticated digital content request {6320, (Fig. 63); Paragraph [0225], 
lines 1, 2 atpg. 115}. 

The method then receives, on the user device, an indication of a user selection of one 
of the one or more clickable links {6398, (Fig. 63); Paragraph [0225], lines 2, 3 at pg. 1 15}. 
The method sends, from the user device, the new authenticated rights locker access request 
and an indication of the right associated with the one of the one or more clickable links to the 
rights locker provider {6325, (Fig. 63); Paragraph [0225], lines 3 to 5 at pg. 116}. Finally, the 
method receives, on the user device from a digital content repository {6370, Fig. 63}, the 
digital content in response to the sending the new authenticated rights locker access request 
{6330, (Fig. 63); Paragraph [0227], line 7 at pg. 1 16}. 



CLAIM 11 

Claim 1 1 includes the limitation of Claim 10 and further defines the method. The 
method determines, on the user device {6300, (Fig. 63); See also 5500, (Fig.55)}, one or more 
delivery parameters. {63 10, (Fig.63); Paragraph [0223], lines 5, 6 at pg. 1 14.} The one or 
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more delivery parameters indicating where the digital content should be sent, a delivery 
mechanism, or both {Paragraph [0188], lines 2, 3 at pg. 99.} In this embodiment, the sending 
the authenticated rights locker access request and the digital content specification further 
comprises sending the one or more delivery parameters. {Paragraph [0223], lines 8, 9 at pg. 
115.} 

CLAIM 12 

Claim 12 includes the limitations of Claim 10 and further defines the method. The 
method stores at least part of the new authenticated rights locker access request in a bookmark 
on the user device {Paragraph [0229], lines 1 to 4 at pg. 1 17}. 

CLAIM 15 

Claim 15 recites a method for digital content access control {Fig. 63}. Initially, the 
method receives, by a rights locker provider {6335, (Fig. 63); See also 5515, (Fig. 55)} from a 
user device{6300, (Fig. 63); See also 5500, (Fig.55)}, a first authenticated rights locker access 
request and a digital content specification. {6340, (Fig. 63); Paragraph [0224], lines 1, 2 at 
pg. 115.} The first authenticated rights locker access request was authenticated by the right 
locker provider for the rights locker. {Paragraph [0208], lines 2 to 4 at pg. 108, and Paragraph 
[0153], lines 6 to 13 atpgs. 82, 83.} 

Next, the rights locker provider validates the first authenticated rights locker access 
request. {6345, (Fig. 63); Paragraph [0224], lines 2, 3 at pg. 1 15}. If the validating indicates 
the first authenticated rights locker access request is valid, the rights locker provider creates a 
Web page with one or more clickable links that comprise an authenticated digital content 
request for use in accessing digital content stored by a digital content repository. {6360, (Fig. 
63); Paragraph [0224], lines 5 to 7 at pg. 114.} 

The rights locker provider sends to the user device, a second authenticated rights 
locker access request for the rights locker and the Web page. {6365, (Fig. 63); Paragraph 
[0224], lines 7 to 11 at pg. 114.} The rights locker provider receives from the user device the 
second authenticated rights locker access request for the rights locker, and validates the 
second authenticated rights locker access request for the rights locker. {6396, (Fig. 63); 
Paragraph [0226], lines 1 to 4 at pg. 116.} The rights locker provider obtains an authenticated 
digital content request if the second authenticated rights locker access request is valid {6396, 
(Fig. 63); Paragraph [0226], lines 4 to 5 at pg. 116.}, and sends the authenticated digital 
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content request to a digital content repository {6396, (Fig. 63); Paragraph [0226], lines 5 to 6 
atpg. 116}. 

CLAIM 16 

Claim 16 includes the limitations of Claim 15 and further defines the method. In the 
method, at least part of said second authenticated rights locker access request is for storage in 
a bookmark on said user device. {Paragraph [0229], lines 4 to 7 at pg. 1 17}. 

CLAIM 28 

Claim 28 recites a program storage device readable by a machine, embodying a 
program of instructions executable by the machine {Paragraph [001 1], lines 8, 9 at pg. 22} to 
perform a method for digital content access control {Fig. 63}. Initially, the method 
determines, on a user device {6300, (Fig. 63); See also 5500, (Fig.55)}, a digital content 
specification and associated authenticated rights locker access request {6305, (Fig. 63); 
Paragraph [0223], lines 4, 5 at pg. 1 14}. The associated authenticated rights locker access 
request was authenticated by a right locker provider for the rights locker. {Paragraph [0208], 
lines 2 to 4 at pg. 108, and Paragraph [0153], lines 6 to 13 at pgs. 82, 83.} 

The method sends, from the user device {6300, (Fig. 63)} to the rights locker provider 
for the rights locker {6335, (Fig. 63)} the authenticated rights locker access request and the 
digital content specification {6315, (Fig. 63); Paragraph [0223], lines 6 to 8at pgs. 1 14, 1 15}. 
Next, the method receives, on the user device from the rights locker provider, a new 
authenticated rights locker access request for the rights locker and a Web page with one or 
more clickable links in response to the sending, at least one of the one or more clickable links 
is associated with an authenticated digital content request {6320, (Fig. 63); Paragraph [0225], 
lines 1, 2 atpg. 115}. 

The method then receives, on the user device, an indication of a user selection of one 
of the one or more clickable links {6398, (Fig. 63); Paragraph [0225], lines 2, 3 at pg. 115}. 
The method sends, from the user device, the new authenticated rights locker access request 
and an indication of the right associated with the one of the one or more clickable links to the 
rights locker provider {6325, (Fig. 63); Paragraph [0225], lines 3 to 5 at pg. 1 16}. Finally, the 
method receives, on the user device from a digital content repository {6370, Fig. 63}, the 
digital content in response to the sending the new authenticated rights locker access request 
{6330, (Fig. 63); Paragraph [0227], line 7 at pg. 1 16}. 
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CLAIM 29 

Claim 29 includes the limitation of Claim 28 and further defines the method. The 
method determines, on said user device {6300, (Fig. 63); See also 5500, (Fig.55)}, one or 
more delivery parameters. {6310, (Fig.63); Paragraph [0223], lines 5, 6 at pg. 1 14.} The one 
or more delivery parameters indicating where said digital content should be sent, a delivery 
mechanism, or both {Paragraph [0188], lines 2, 3 at pg. 99.} In this embodiment, the sending 
said authenticated rights locker access request and said digital content specification further 
comprises sending said one or more delivery parameters. {Paragraph [0223], lines 8, 9 at pg. 
115.} 



CLAIM 30 

Claim 30 includes the limitations of Claim 28 and further defines the method. The 
method stores at least part of said new authenticated rights locker access request in a 
bookmark on said user device {Paragraph [0229], lines 1 to 4 at pg. 117}. 



CLAIM 33 

Claim 33 recites a program storage device readable by a machine, embodying a 
program of instructions executable by the machine {Paragraph [001 1], lines 8, 9 at pg. 22} to 
perform a method for digital content access control {Fig. 63}. 33. Initially, the method 
receives, by a rights locker provider {6335, (Fig. 63); See also 5515, (Fig. 55)} from a user 
device {6300, (Fig. 63); See also 5500, (Fig.55)}, a first authenticated rights locker access 
request and a digital content specification. {6340, (Fig. 63); Paragraph [0224], lines 1, 2 at 
pg. 115.} The first authenticated rights locker access request was authenticated by the right 
locker provider for the rights locker. {Paragraph [0208], lines 2 to 4 at pg. 108, and Paragraph 
[0153], lines 6 to 13 at pgs. 82, 83.} 

Next, the rights locker provider validates the first authenticated rights locker access 
request. {6345, (Fig. 63); Paragraph [0224], lines 2, 3 at pg. 115}. If the validating indicates 
the first authenticated rights locker access request is valid, the rights locker provider creates a 
Web page with one or more clickable links that comprise an authenticated digital content 
request for use in accessing digital content stored by a digital content repository. {6360, (Fig. 
63); Paragraph [0224], lines 5 to 7 at pg. 1 14.} 

The rights locker provider sends to the user device, a second authenticated rights 
locker access request for the rights locker and the Web page. {6365, (Fig. 63); Paragraph 
[0224], lines 7 to 1 1 at pg. 1 14.} The rights locker provider receives from the user device the 
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second authenticated rights locker access request for the rights locker, and validates the 
second authenticated rights locker access request for the rights locker. {6396, (Fig. 63); 
Paragraph [0226], lines 1 to 4 at pg. 1 16.} The rights locker provider obtains an authenticated 
digital content request if the second authenticated rights locker access request is valid {6396, 
(Fig. 63); Paragraph [0226], lines 4 to 5 at pg. 116.}, and sends the authenticated digital 
content request to a digital content repository {6396, (Fig. 63); Paragraph [0226], lines 5 to 6 
atpg. 116}. 

CLAIM 34 

Claim 34 includes the limitations of Claim 33 and further defines the method. In the 
method, at least part of said second authenticated rights locker access request is for storage in 
a bookmark on said user device. {Paragraph [0229], lines 4 to 7 at pg. 117.} 

CLAIM 72 

Claim 72 recites an apparatus for digital content access control. The apparatus 
includes a memory for storing digital content and a processor. {Paragraph [001 1], lines 1 to 9 
atpg. 22.} 

Initially, the processor is configured to determine, on a user device {6300, (Fig. 63); 
See also 5500, (Fig.55)}, a digital content specification and associated authenticated rights 
locker access request {6305, (Fig. 63); Paragraph [0223], lines 4, 5 at pg. 1 14}. The 
associated authenticated rights locker access request was authenticated by a right locker 
provider for the rights locker. {Paragraph [0208], lines 2 to 4 at pg. 108, and Paragraph 
[0153], lines 6 to 13atpgs. 82, 83.} 

The processor is also configured to send, from the user device {6300, (Fig. 63)} to the 
rights locker provider for the rights locker {6335, (Fig. 63)} the authenticated rights locker 
access request and the digital content specification {6315, (Fig. 63); Paragraph [0223], lines 6 
to 8at pgs. 114, 115}. Next, the method receives, on the user device from the rights locker 
provider, a new authenticated rights locker access request for the rights locker and a Web page 
with one or more clickable links in response to the sending, at least one of the one or more 
clickable links is associated with an authenticated digital content request {6320, (Fig. 63); 
Paragraph [0225], lines 1, 2 at pg. 1 15}. 

In addition, the processor is configured to receive, on the user device, an indication of 
a user selection of one of the one or more clickable links {6398, (Fig. 63); Paragraph [0225], 
lines 2, 3 at pg. 115}. The processor is configured to send, from the user device, the new 
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authenticated rights locker access request and an indication of the right associated with the one 
of the one or more clickable links to the rights locker provider {6325, (Fig. 63); Paragraph 
[0225], lines 3 to 5 at pg. 116}. Finally, the processor is configured to receive, on the user 
device from a digital content repository {6370, Fig. 63}, the digital content in response to the 
sending the new authenticated rights locker access request {6330, (Fig. 63); Paragraph [0227], 
line 7 atpg. 116}. 

CLAIM 73 

Claim 73 includes the limitation of Claim 72 and further defines the processor 
configuration. The processor is configured to determine, on the user device {6300, (Fig. 63); 
See also 5500, (Fig.55)}, one or more delivery parameters. {63 10, (Fig.63); Paragraph 
[0223], lines 5, 6 at pg. 114.} The one or more delivery parameters indicate where the digital 
content should be sent, a delivery mechanism, or both. {Paragraph [0188], lines 2, 3 at pg. 
99.} In this embodiment, the sending the authenticated rights locker access request and the 
digital content specification further comprises sending the one or more delivery parameters. 
{Paragraph [0223], lines 8, 9 at pg. 115.} 

CLAIM 82 

Claim 82 includes the limitations of Claim 72 and further defines the processor 
configuration. The processor is configured to store at least part of the new authenticated rights 
locker access request in a bookmark on the user device {Paragraph [0229], lines 1 to 4 at pg. 
117}. 

CLAIM 85 

Claim 85 recites an apparatus for digital content access control. The apparatus 
includes a memory for storing one or more rights lockers that describe digital content access 
rights and a processor. {Paragraph [0026], lines 1 to 4 at pg. 26 and 5515 in Fig. 55.} 

The processor is configured to receive, by a rights locker provider {6335, (Fig. 63); 
See also 5515, (Fig. 55)} from a user device{6300, (Fig. 63); See also 5500, (Fig.55)}, a first 
authenticated rights locker access request and a digital content specification. {6340, (Fig. 63); 
Paragraph [0224], lines 1, 2 at pg. 1 15.} The first authenticated rights locker access request 
was authenticated by the right locker provider for the rights locker. {Paragraph [0208], lines 2 
to 4 at pg. 108, and Paragraph [0153], lines 6 to 13 at pgs. 82, 83.} 




Page 11 of 42 



Serial No. 10/687,459 

Notice of Appeal Entered: June 18, 2010 

Appeal Brief Filed: August 18, 2010 



Next, the processor is configured to validate, by the rights locker provider, the first 
authenticated rights locker access request. {6345, (Fig. 63); Paragraph [0224], lines 2, 3 at pg. 
115}. If the validating indicates the first authenticated rights locker access request is valid, the 
processor is configured to create a Web page, by the rights locker provider, with one or more 
clickable links that comprise an authenticated digital content request for use in accessing 
digital content stored by a digital content repository. {6360, (Fig. 63); Paragraph [0224], lines 
5 to 7 at pg. 114.} 

The processor is configured to send, by rights locker provider to the user device, a 
second authenticated rights locker access request for the rights locker and the Web page. 
{6365, (Fig. 63); Paragraph [0224], lines 7 to 1 1 at pg. 1 14.} The processor is configured to 
receive by the rights locker provider from the user device the second authenticated rights 
locker access request for the rights locker, and to validate the second authenticated rights 
locker access request for the rights locker. {6396, (Fig. 63); Paragraph [0226], lines 1 to 4 at 
pg. 116.} The processor is configured to obtain, by the rights locker provider, an 
authenticated digital content request if the second authenticated rights locker access request is 
valid {6396, (Fig. 63); Paragraph [0226], lines 4 to 5 at pg. 1 16.}, and the processor is 
configured to send the authenticated digital content request to a digital content repository 
{6396, (Fig. 63); Paragraph [0226], lines 5 to 6 at pg. 116}. 

CLAIM 86 

Claim 86 includes the limitations of Claim 85 and further defines the apparatus such 
that at least part of said second authenticated rights locker access request is for storage in a 
bookmark on said user device. {Paragraph [0229], lines 4 to 7 at pg. 117}. 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Whether Claims 10, 14, 28, 32, 72, and 84 are unpatentable under 35 U.S.C. 

§ 102(e) as being anticipated by U.S. Patent Application Publication No. US 2004/0024652 
Al? 

2. Whether Claims 1 1, 29, and 73 are unpatentable under 35 U.S.C. § 102(e) as being 
anticipated by U.S. Patent Application Publication No. US 2004/0024652 Al? 

3. Whether Claims 12, 30, and 82 are unpatentable under 35 U.S.C. § 103(a) as being 
obvious over U.S. Patent Application Publication No. US 2004/0024652 Al in view of U.S. 
Patent No. 7,136,631? 

4. Whether Claims 15, 18, 33, 36, 85, and 88 are unpatentable under 35 U.S.C. § 
102(e) as being anticipated by U.S. Patent Application Publication No. US 2004/0024652 Al? 

5. Whether Claims 16, 34, and 86 are unpatentable under 35 U.S.C. § 103(a) as being 
obvious over U.S. Patent Application Publication No. US 2004/0024652 Al in view of U.S. 
Patent No. 7,136,631? 
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ARGUMENT 



1. CLAIMS 10, 14. 28. 32. 72, and 84 ARE PATENTABLE FOR MULTIPLE 
REASONS. 

The rejection of 10, 14, 28, 32, 72, and 84 as being anticipated by U.S. Patent 
Application Publication No. US 2004/0024652 Al, hereinafter referred to as Buhse, is in error 
for multiple reasons and should be withdrawn. 

As demonstrated more completely below, the rejection fails to comply with the 
multiple MPEP requirements for an anticipation rejection. The rejection has failed to consider 
the plain meaning of the claims and has failed to consider all claims limitations. The rejection 
reduces express claim limitations to a gist and even then fails to demonstrate that the reference 
teaches the gist in the same level of detail and arranged as required by the claims. The 
rejection has failed to meet the MPEP requirements for an anticipation rejection and has not 
even made a valid obviousness rejection. 

Buhse teaches the following three different scenarios in which his invention can be 
used: (i) a distributor/retail integration scenario where a consumer purchases a product and a 
distributor tracks the sale (Buhse, Paragraphs [0047] to [0054] at pg. 3.); (ii) a subscription 
scenario where a digital subscription plan is offered to a consumer (Buhse, Paragraphs [0055] 
to [0063] at pgs. 3, 4.); and (iii) a promotional scenario where a consumer receives a digital 
product at no cost in exchange for leaving valuable user information (Buhse, Paragraphs 
[0064] to [0071] at pg. 4). Buhse teaches that the various scenarios are distinct, and are for 
different purposes. 

As described more completely below, the rejection starts with pieces of the third 
scenario. However, instead of relying upon the third scenario with respect to the entire claim, 
the rejection extracts pieces from the first and second scenarios and recombines the extracted 
pieces with the third scenario according to Appellant's claim language and not any teaching in 
Buhse. 

The rejection also extracts pieces from Paragraph [0185] of Buhse concerning 
purchase requests associated with scenarios one and two and recombines the teachings 
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concerning purchase requests with teachings of Buhse concerning the third promotional 
scenario that requires only user information and not a purchase. 

Both of these extractions and recombinations would be improper in an obviousness 
rejection and so cannot be used to support an anticipation rejection. MPEP §2131,8 Ed., 
Rev. 8, p. 2100-67 (July 2010) sets the anticipation standard. The MPEP unambiguously 
states that a claim element " must be " shown in as complete detail and arranged as required by 
the claim. This is not a permissive standard, but rather one with which the rejection is 
required to comply. Further, it is not enough that the rejection finds similar elements in 
Buhse. This standard also requires that Buhse must teach that the elements are arranged as 
required by the claims. 

Thus, the above observations alone are sufficient to demonstrate that a proper 
anticipation rejection has not been made. In addition to these errors, the rejection is disjointed 
and cites the same thing over and over as teaching exactly different elements of the claims. 
The rejection fails to identify and provide an interpretation of an element of a claim and then 
use that interpretation consistently in all claim limitations in which that element is recited. 

Claim 10 is used as an example of Claims 10, 28, and 72. Claims 28 and 72 include 
equivalent or similar limitations to those discussed below with respect to Claim 10. 

All the processes recited in Claim 10 are performed on a single device, a user device. 
The method uses authenticated digital content requests embedded in a Web page having 
clickable links for indirect digital content access control. 

Claim 10 includes a user device, a rights locker provider, and a content repository. 
Claim 10 also recites three authenticated requests — "a digital content specification and 
associated authenticated rights locker access request," "a new authenticated rights locker 
access request," and "at least one of said one or more clickable links associated with an 
authenticated digital contend request." An authenticated request is well understood in the art 
and is different from some arbitrary access request or log-in. 

Two of the access requests are specific requests "rights locker access requests." 
According to the claim, these access requests are for access to a rights locker that is provided 
by the rights locker provider. Also, in these claims, the user device sends and receives 
specific items in a specific sequence from a rights locker provider. The user device also 
receives specific items from a content repository following the interactions with the rights 
locker provider. 
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This interpretation follows from the plain meaning of the claim and so is not open to 
interpretation by the Examiner. The MPEP requires that "words of the claim must be given 
their plain meaning unless the plain meaning is inconsistent with the specification." MPEP § 
21 1 1.01, 1., 8th Ed. Rev. 8, p 2100-38 (July 2010). 

In the following remarks, Appellant steps through each limitation of Claim 10 and 
demonstrates that not only has the Examiner failed to establish an anticipation rejection, but 
also the rejection failed to comply with the standards for an obviousness rejection. A showing 
with respect to one limitation is sufficient to overcome the anticipation rejection. 
Nevertheless, the numerous errors are individually pointed out so that the Office cannot argue 
that Appellant has waived the right to assert the error. 



1.1 Buhse fails to teach the determining recited in Claims 

The first limitation in Claim 10 recites: 



determining, on a user device, a digital content specification and associated 
authenticated rights locker access request wherein said associated authenticated rights 
locker access request was authenticated by a right locker provider for the rights locker ; 
(Emphasis Added.) 



Claim 10, lines 3 to 7. 

Thus, the determining process is done on the user device. The digital content 
specification is associated with the authenticated rights locker access request. The 
authenticated rights locker access request is tied to a specific thing, the digital content 
specification. 

The authenticated rights locker access request is not just any authenticated request. In 
particular, the access request is not an identifier for a promotion, as in Buhse, but rather a 
specific type of request, "an authenticated rights locker access request." As recited in 
Claim 10, the access request was authenticated by a specific party-a rights locker provider for 
the rights locker. Since the access request has already been authenticated, the request does not 
require authentication when used. 

Based on nothing but the plain meaning of this part of Claim 10, the rejection must 
cite a teaching of a rights locker, identify the provider for that rights locker, and then 
demonstrate that that particular provider authenticated the request that is determined in this 
process of Claim 10. This was not done in the rejection and instead, the explicit recitation 
was reduced to a gist of logging in with a promotion ID and downloading something from 
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some location that provides some rights management. (See FOA dated 2/18/2010, Section 9, 
last line on pg 6 to top of pg. 7, which is quoted below.) 

The Examiner justifies this inappropriate level of analysis by stating: 

...it is noted that the features upon which applicant relies (i.e., "a rights locker, identify 
the provider for that locker and then demonstrate that that particular provider 
authenticated the request that is determined in this operation.") are not recited in the 
rejected claim(s) 

Advisory Action, Paragraph Per 1. a), lines 1 to 3 dated 5/13/2010 at pg. 2. 
This is error. As quoted above, Claim 10 recites: 

wherein said associated authenticated rights locker access request was 
authenticated by a right locker provider for the rights locker. 

The above interpretation provided by Appellant is simply the plain meaning of the 
claim language. The claim expressly states that the rights locker provider authenticated the 
access request, and that the rights locker provider provides the rights locker. Accordingly, the 
Examiner has admitted on the record that both the plain meaning and express claim limitations 
were ignored. 

With respect to the above limitation of Claim 10, the Final Office action stated: 

(pars. 0029-0030, 0042, and 0065-0066; Figs. 1 and 2C; step 1 and steps 4a: 'select 
content '; the Offer Catalog Component 102 accessible by customers, provides 
customers with a listing of the digital products available from each client; in response 
to the client or prescriptions directions, the Rights locker Component 104 issued 
purchased products to the customer; the consumer logs in using the promotion ID; see 
also pars. 0064-0072) (Emphasis in original.) 

FOA dated 2/18/2010, Section 9, last line on pg 6 to top of pg. 7. 

The rejection is relying upon the third scenario in Paragraphs [0064] to [0071] of 
Buhse, as stated above. Nowhere in the cited sections of Buhse is an authenticated access 
request mentioned and so the reference cannot teach the specific authenticated access request 
recited in these claims. To see if there are teachings of authentication anywhere in Buhse, 
Appellant electronically searched the text version of Buhse available on the USPTO website 
for "authen" and there were no hits. 
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However, the Examiner takes exception to this interpretation by stating in the 
Advisory Action: 



The Examiner respectfully submits that Bushe does teach the specific authenticated 
access request as claimed by the Applicants (par. 0065; the consumer logs in user the 
promotion ID; [meaning the system will authenticate user using promotion ID]; pars. 
0135 and 0185-0190; 



Advisory Action, Paragraph Per 2. a), lines 3 to 6 dated 5/13/2010 at pg. 3 

The citations in this part of the advisory action fail to establish that the promotion ID 
of Buhse is an authenticated rights locker access request. A general login to a site using a 
promotion ID as described in Paragraph [0065] of Buhse fails to suggest or disclose anything 
about a rights locker access request, which is a request to access a specific thing, "a rights 
locker." (See specification, Paragraph [0020] at pg. 24.) 

Paragraphs [0135] and [0185] to [0190] of Buhse do not mention the promotion ID 
and so cannot support the Examiner's analysis. As pointed out in further detail below, 
Paragraph [0185] is not related to the third scenario upon which the Examiner is relying. The 
third scenario does not include a purchase (See Buhse, Paragraph [0064] at pg. 4). 

The rejection effectively admits that Buhse fails to teach the invention in the same 
level of detail by reducing the explicit claim language to a gist — a login using a promotion ID, 
where the login is subsequently authenticated according to the Examiner. Buhse does not 
characterize the log-in in Paragraph [0065] and so the authentication is simply Examiner 
conjecture. Further, since the Examiner admits that the authentication must be performed by 
the system on log-in, it is an admission that the original access request that was sent from the 
user device was not authenticated. 

Assuming that the unsupported conjecture concerning authentication on log-in were 
correct, such an authentication is unrelated to determination of an authenticated rights locker 
access request on the user device as recited in Claim 10. Thus, the Examiner's own analysis 
demonstrates that a specific access request has been reduced to a gist, i.e., to just some log-in 
attempt, on a device different from the user device, which might for some unexplained reason 
require authentication. 

In essence, the Examiner is arguing at best an improper inherency. With respect to 
inherency the MPEP directs "Inherency, however, may not be established by probabilities or 
possibilities. The mere fact that a certain thing may result from a given set of circumstances is 
not sufficient." MPEP § 21 12 IV., 8 th Ed. Rev. 8, p. 2100-47 (July 2010). 
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In Buhse, there is no description of anything being authenticated. In Bhuse, there is no 
description of the Promotion ID and the only instance of that term is in Paragraph [0065] of 
Buhse, which says nothing about how the promotion ID is processed or the characteristics of 
the promotion ID. There is no showing in either the Final Rejection or the Advisory Action 
that Buhse teaches the promotion ID is an authenticated promotion ID, or teaches that the 
promotion ID is a request to access a rights locker. 

The entire conjecture by the Examiner is nothing but probabilities or possibilities 
based on Appellant's claim language, and not based on any teaching in Buhse. Accordingly, 
the "mere fact that a certain thing may result from a given set of circumstances is not 
sufficient" to support an anticipation rejection according to the MPEP. This is further 
evidence that a proper anticipation rejection has not been made. 

Since the rejection failed to cite any teaching or suggestion of an authenticated rights 
locker access request, the arguments in the final rejection and the advisory action concerning 
what is associated with the promotion ID are basically irrelevant because the initial premise of 
the rejection with respect to the promotion ID is wrong and not supported by any teaching or 
suggestion in Buhse. Appellant's claim language is being used as roadmap for the 
interpretation, which is an impermissible level of analysis. MPEP § 2142, 8 th Ed., Rev. 7, pg 
2100-127 (July, 2008), "impermissible hindsight must be avoided." 

The above distinctions alone are sufficient to overcome the anticipation rejection. 
Nevertheless, Appellant points out further errors in the rejection to avoid any waiver. 

1.2 Buhse fails to teach the first sending recited in Claim 10 

The next limitation of Claim 10 recites: 

sending, from said user device to said rights locker provider for the rights 
locker, said authenticated rights locker access request and said digital content 
specification 

Claim 10, lines 8 to 11. 

The plain meaning of this claim limitation is that the authenticated rights locker access 
request and the associated digital content specification are sent from the user device to a 
specific entity, "said rights locker provider for the rights locker." The two items are sent to the 
entity — the rights locker provider for the rights locker-that authenticated the access request in 
the first portion of the claim. 
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The rejection does not cite sending of two items to any entity that authenticated one of 
the items being sent. Instead, with respect to this limitation of Claim 10, the FOA stated: 

(pars. 0029-0033, 0066, 0156-0159, and 0166; Figs. 1 and 2C; step 4a: 'select 
content'; the consumer selects the products to be downloaded and submits the request 
for content; the Rights Locker Component (RLC) 104 maintains a Rights Database, 
which contains rights information for each consumer; see also pars. 0064-0072, 0102- 
0110, and 0124-0135) (Emphasis in original.) 

FOA dated 2/18/2010, Section 9, end of first complete paragraph of pg. 7. 

The rejection is still relying upon the third scenario of Buhse in Paragraphs [0064] to 
[0071]. This part of the rejection does not cite to anything determined in the first process 
which are the elements sent in the claim and instead cites to completely different operations in 
Buhse. 

The rejection completely ignores the express relationship between the first and second 
portions of the claim and the elements recited in those portions. The rejection has failed to 
cite any teaching in Buhse that either the promotion ID or the selection of content is an access 
request to a rights locker provided by Buhse. For example, the rejection has not demonstrated 
that the promotion ID or the selection of content is a request to access anything associated 
with the Rights Locker Component of Buhse. Such a showing is required by the MPEP to 
establish an anticipation rejection. 

Thus, yet again express limitations are reduced to a gist and the gist is rejected. The 
rejection has failed to cite any teaching of sending two items as recited in this portion of the 
claim to a rights locker provider that authenticated one of the two items before that item was 
sent. As noted above, the Examiner admits that conjectured authentication occurs after the 
log-in and only after the promotion ID is sent. Therefore, under the hypothetical unsupported 
scenario put forth by the Examiner, it cannot be determined that the promotion ID is an 
authenticated rights locker access request prior to the sending as required in Claim 10. This 
alone is also is sufficient to overcome the anticipation rejection. 

1.3 Buhse fails to teach the first receiving recited in Claim 10 

The next limitation of Claim 10 recites: 

receiving, on said user device from said rights locker provider, a new 
authenticated rights locker access request for the rights locker and a Web page with 
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one or more clickable links in response to said sending, at least one of said one or 
more clickable links associated with an authenticated digital content request 

Claim 10, lines 12 to 18. 

Again, based on nothing but the plain meaning of this limitation of Claim 10, the 
rejection must show that the user device receives a response from the rights locker provider, 
which includes two items: a new authenticated rights locker access request and a Web page 
with links with at least one of the links is associated with an authenticated digital content 
request. 

In this part of Claim 1 0, two specific elements are involved in the receiving, the user 
device and the rights locker provider. This is the same rights locker provider discussed above 
with respect to the first two limitations of the claim. 

A showing of a Web page with links as cited in Advisory Action is not sufficient. (See 
Advisory Action, Paragraph Per 1. c), line 5 dated 5/13/2010 at pg. 3.) The rejection must cite 
a showing of a Web page with at least one link associated with an authenticated digital content 
request, which is a specific authenticated request. 

With respect to this limitation of the claim, the rejection stated: 

(pars. 0033, 0067-0068, 01 56-0 J 59, and 0165-0166; Fig. 2C; step 6a: 'download SW 
request '; the Rights Locker Component (RLC) 104 is the client's branded customer 
interface; the consumer is prompted to download software needed to play the content; 
see also pars. 0047-0062, 0064-0071, and 0169-0172) (Emphasis in original.) 

FOA dated 2/18/2010, Section 9, end of second complete paragraph of pg. 7. 

As pointed out above with respect to the first two portions of Claim 10, the rejection 
relies upon the third scenario. However, with respect to this third portion of Claim 1 0, the 
rejection also pulls in both the first and second scenarios in Paragraph [0047] to [0062] of 
Buhse in combination with the third scenario. 

In the third scenario, Buhse stated at pg. 3: 

[0066] 2. The Consumer selects the product to be downloaded and submits the 
request for content (4a). 

[0067] 3. The OMS 105 retrieves product information from the OCC 102 (5a). 

[0068] 4. The Consumer is prompted to download software needed to play the 
content. (For example, a player or DRM-specific software) (6a). 

[0069] 5. The OMS 105 updates the RLC 104 with the new content/rights (8a). 

[0070] 6. The OMS 105 updates the promotion site, and the selected products 
are downloaded to the Consumer device (9b). 

Page 21 of 42 



Serial No. 10/687,459 

Notice of Appeal Entered: June 18, 2010 

Appeal Brief Filed: August 18, 2010 



Again, the rejection failed to cite to any authenticated access request in these 
paragraphs, let alone two different types of authenticated requests as recited in this portion of 
the claim. Further, the authenticated rights locker access request is the same type of access 
request as recited in the first portion of the claim, except the access request in this portion is 
new. There is no consistency in this part of the rejection with the rejection of the first two 
portions of Claim 10. The rejection has failed to cite two of the same type of request in a 
process of Buhse, where the one that occurs later in time is new. 

To justify the disjointed rejection, the Advisory Action argued: 

c) Bushe does disclose the party that authenticated the original access request sends to 
the user device a new access request and a Web page (pars. 0029-0030, 0042, and 
0065-0066; Figs. 1 and 2C; step 1 and steps 4a: 'select content'; the consumer logs in 
using the promotion ID; and then pars. 0055-0063, 0068, and 0185-0190; Figs. 2C and 
7C; step 6b: 'SW downloaded'). As described in paragraphs [0185]-[0190], after 
authenticating the user and determining that the user/account holder is authorized to 
have the requested content, the user will receive result returned in the form of links 
[i.e., a Web page includes links] to retrieve the content. 

Advisory Action, Paragraph Per 1. c), lines 1 to 5 dated 5/13/2010 at pg. 3. See also, 
Advisory Action, Paragraph Per 2. d), lines 1 to 6 dated 5/13/2010 at pg. 3, which repeats this 
statement. 

Again, this makes Appellant's point. The Examiner is pointing back to the things that 
were cited with respect to the first limitation of Claim 1 0, the select content and promotion ID 
and simply adds the software download. There are not multiple promotion IDs in Buhse, but 
yet the rejection cites to the one instance of a promotion ID as teaching several different 
elements in Claim 10. If the Promotion ID is the authenticated rights locker request in the 
determining process of Claim 10, the Promotion ID cannot be the new authenticated rights 
locker request in this portion of the claim. As noted above, the rejection is disjointed and fails 
to consistently treat the different elements recited in the claims. All of these are examples of 
yet further errors. 

Also, in this part of the rejection, the Examiner starts with the third scenario of Buhse 
at Paragraph [0065] and [0066]. The Examiner then jumps to the second scenario in 
Paragraphs [0055] to [0063] and then goes back to Paragraph [0068] in the third scenario. In 
an anticipation rejection there is no basis for extracting two operations in one scenario, going 
to a different scenario and extracting a part of that scenario, and then returning to the third 
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scenario and arguing that the scenario created by the selective recombination of the two 
scenarios is anticipation. This cannot be done in an obviousness rejection because the 
recombination changes the principles of operation of Buhse as taught by the different 
scenarios. The selective extraction and recombination is clear error. 

Further, based on the recombination, the Examiner again makes up things that are not 
taught by Buhse. The Examiner makes up a Web page that is neither taught nor suggested by 
Buhse with respect to the third scenario that was the basis for the rejection of the earlier parts 
of Claim 10. With respect to the third scenario of Buhse, there is no teaching of "the user will 
receive result returned in the form of links [i.e., a Web page includes links] to retrieve the 
content." 

Such a web page is unnecessary in the third scenario and the only selection is the 
selection in the third scenario as described in Paragraph [0066]. Once the selection is made, 
the content is sent to the consumer without a further selection by the consumer. See the above 
quotation of Paragraphs [0066] to [0070] from Buhse. Thus, the Examiner's conclusion 
concerning a web-page is apparently based on Paragraph [0056] of the second scenario. 
Again, in an anticipation rejection, it is improper to mix and match different parts of Buhse. 

The web links in Paragraph [0185] are not associated with the third scenario that does 
not require a purchase, but rather with purchase requests and subscription purchases. Even if 
the web links could be pulled into the third scenario, there is no showing that any of the web 
links are "associated with an authenticated digital content request," are recited in Claim 10. 
Citing to only web links is showing only the gist of the express claim limitations and is 
improper in an obviousness rejection and so cannot form the basis for an anticipation 
rejection. 

Again, the express claim limitation has been reduced to a gist, just some web links. As 
noted previously, Buhse does not include any word starting with "authen" and so fails to teach 
the specific web link recited in this part of the claim. This is further evidence of taking parts 
of Buhse out of context and reapplying them in a context, the third scenario that does not 
require a purchase of any type according to Buhse, and also interpreting the extracted pieces 
based at best on probabilities or possibilities. Both of these are an improper form of analysis 
for an anticipation rejection and so this limitation also distinguishes over Buhse. 



1.4 Buhse fails to teach the second receiving recited in ClaimlO 

The next limitation of Claim 10 recites: 
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receiving, on said user device, an indication of a user selection of one of said 
one or more clickable links; 

Claim 10, lines 19 to 21. 

The user selection in this limitation of Claim 10 occurs after the new authenticated 
rights locker access request and the Web page are received on the user device. The rejection 
ignores the time sequence in the claims. The rejection yet again takes elements from scenarios 
one and two of Buhse and injects them in scenario three, where they are neither taught nor 
needed. 

Specifically, the rejection stated: 

(par. 0068; Fig. 2C; step 6a: 'download SW request '; the consumer is prompted to 
download software needed to play the content; see also pars. 0055-0063, ,0156- 
0159,0165-0166, and 0185-0190; the Consumer visits a retail website or a Rights 
Locker website to view the subscription plan (playlist) and selects tracks to download; 
the result returned is either in the form of links to retrieve the content, or proprietary 
order 6/ocfoXEmphasis in original.) 

FOA dated 2/18/2010, Section 9, end of last paragraph on pg. 7 to top of page 8. 

As noted above with respect to the first two portions of Claim 10, the rejection relies 
upon the third scenario of Buhse. With respect the third portion, the rejection combines pieces 
from the second scenario with the third scenario and unrelated purchase processing. Here, the 
rejection starts with the third scenario and Paragraph [0068], but to booster to the improper 
rejection paraphrases language from Paragraph [0185] of Buhse, which concerns purchase 
requests, i.e., 

[0185] Purchase requests and subscription purchases are first processed through the 
AMG/AMC. The AMC indicates to OMS whether the account holder is authorized to 
have the requested content. If so, OMS generates the entitlements for the indicated 
content, and returns the result to the requestor. The result returned is either in the form 
of links to retrieve the content, or proprietary order blocks, which are processed by the 
Content Manager on the client's equipment. 

The third scenario provides "a digital product at no cost in exchange for leaving 
valuable user information." (Buhse, Paragraph [0064] at pg. 4) Thus, the rejection proposes 
to modify the third scenario to include processing associated with the first and second 
scenarios, processing that is directly taught away from by the third scenario of Buhse. Hence, 
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this mixing and matching could not be done in an obviousness rejection and so cannot form 
the basis for an anticipation rejection. Appellant pointed out to the Examiner in response to 
the first office action that the teaching of Buhse must be taken in context (Paper dated October 
21, 2009, next to last paragraph on pg. 24; see also second complete paragraph on pg. 26), and 
still in both the Final Office Action and the Advisory Action, the Examiner mixes and 
matches pieces of the different scenarios based only upon Appellant's claims language and no 
teaching in Buhse. Accordingly, this limitation of Claim 10 also distinguishes over Buhse. 

1.5 Buhse fails to teach the second sending recited in Claim 10 

The next limitation of Claim 10 recites: 

sending, from said user device, said new authenticated rights locker access 
request and an indication of the right associated with said one of said one or more 
clickable links to said rights locker provider; 

Claim 10, lines 22 to 26. 

Here, the user device sends to the rights locker provider two items again — the new 
authenticated rights locker access request and an indication of the right associated with the one 
of the one or more clickable links. Yet again, the rejection takes elements from scenarios one 
and two of Buhse and injects them in scenario three, where they are neither taught nor needed. 
In addition, the rejection takes elements at the start of scenarios one and two and moves them 
into a later in time sequence recited in this limitation of Claim 10 

Specifically, the rejection stated: 

(pars. 0055-0063, 0068, and 0185-0190; Figs. 2C and 7C; step 6b: 'SW downloaded'; 
the Consumer visits a retail website or a Rights Locker website to view the 
subscription plan (playlist) and selects tracks to download; the result returned is 
either in the form of links to retrieve the content, or proprietary order blocks; see also 
pars. 0106, 0155-0157, and 0165-0166; the consumer determines which rights to 
transfer to other devices) (Emphasis in original.) 

FOA dated 2/1 8/2010, Section 9, end of first complete paragraph on page 8. 

The rejection starts with Paragraph [0056] in the second scenario and then extracts a 
part of paragraph [0185] and then returns to paragraph [0068] in the third scenario of Buhse. 
The rejection still has not cited a new authenticated rights locker access request or cited a 
teaching that the link in the Web page had any associated authentication. A general request to 
download something fails to teach anything about authentication or the type of request sent to 
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initiate the download in Buhse. Further, the fact that rights management may be used does not 
teach that a request is authenticated. To the extent that the rejection may be relying upon 
some unstated inherency, this is error. 

As quoted above from MPEP § 21 12, IV., 8 th Ed., Rev. 7, pg. 2100-47 (July, 2008), 
the fact that there is a possibility that a rights management system may include an 
authenticated request is not sufficient. The mere fact that some authentication may result from 
a rights management system is not sufficient according to the MPEP. Further, even if it were 
sufficient, general knowledge of authentication does not teach or suggest the specific 
limitations recited in these claims. This is further evidence that the anticipation rejection is 
not well founded. 



1.6 Buhse fails to teach the third receiving recited in Claim 10 

The last limitation of Claim 10 recites: 

receiving, on said user device from a digital content repository, said digital 
content in response to said sending said new authenticated rights locker access request; 

Claim 10, lines 27 to 30. Here, the user device receives the digital content an entity different 
from the rights locker provider in response to the sending of the new authenticated rights 
locker access request. 

With respect to this claim limitation, the Final Rejection stated: 

(pars. 0069-0071; Fig. 2C; step 9b: 'product receipt '; the OMS 105 updates the 
promotion site, and selected products are downloaded to the Consumer device; pars. 
0155-0161, 0169-0172, and 0185-0190; Figs. 2C and 7C; FIG. 7C; OMS creates a 
new license using the required DRM product, and returns the result to the user). 

FOA dated 2/18/2010, Section 9, end of second complete paragraph on page 8. 

The rejection reverts to the third scenario of Buhse. The cited portion says only that 
the selected products are downloaded. Again explicit claim limitations are reduced to a gist. 
The rejection has not cited any teaching or suggestion of from what entity the product is 
downloaded and so has failed to show that Buhse teaches the invention in the same level of 
detail as recited in Claim 10. Finally, the rejection does not relate the content received to 
anything that was cited in the previous portions that was purported to teach the "new 
authenticated rights locker access request." This also is sufficient to overcome the 
anticipation rejection. 
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Appellant has demonstrated multiple reasons why Buhse fails to meet the requirement 
of the MPEP for an anticipation rejection. Only one of the numerous showings is needed to 
overcome the anticipation rejection. Appellant respectfully requests reconsideration and 
withdrawal of the anticipation rejection of each of Claims 10, 28, and 72. 

Claims 14, 32, and 84 are patentable for at least the same reasons as Claims 10, 28, 
and 72. Appellant respectfully requests reconsideration and withdrawal of the anticipation 
rejection of each of Claims 14, 32, and 84. 

2. CLAIMS 11, 29, and 73 ARE PATENTABLE OVER BUHSE 

The rejection of Claims 1 1, 29, and 73 as being anticipated by U.S. Patent Application 
Publication No. US 2004/0024652 Al, hereinafter referred to as Buhse, is in error and should 
be withdrawn. The rejection fails to comply with the MPEP requirements for anticipation by 
failing to show that Buhse shows the invention in the same level of detail and arranged as 
required by these claims. 

Claim 1 1 depends from Claim 10. Claim 29 depends from Claim 28, and Claim 73 
depends from Claim 72. Claim 1 1 is used as an example. Claims 29 and 73 include 
equivalent or similar limitations to those discussed below with respect to Claim 1 1 . 

Claim 1 1 recites that specific delivery parameters are determined on the user device 
and then sent in the first sending process of Claim 10. 

The rejection cited to prompting a user to download software. (FOA dated 2/18/2010, 
Section 9, end of last paragraph on page 8 and top of page 9.) Prompting a user to download 
software teaches or suggests nothing about " said one or more delivery parameters indicating 
where said digital content should be sent, a delivery mechanism, or both," as recited in 
Claim 1 1 . Therefore, the rejection has failed to demonstrate that Buhse teaches Claim 1 1 in 
the same detail and arranged as required by Claim 11. Thus, each of Claims 1 1, 29, and 73 
distinguishes over Buhse for reasons in addition to the Claims from which they depend. 
Appellant respectfully requests withdrawal of the anticipation rejection of each of Claims 11, 
29 and 73. 

3. CLAIMS 12, 30, and 82 ARE PATENTABLE OVER BUHSE 

The rejection of Claims 12, 30, and 82 as being unpatentable over U.S. Patent 
Application Publication No. US 2004/0024652 Al (Buhse) in view of U.S. Patent No. 
7,136,63 1, hereinafter referred to as Jiang, is in error and should be withdrawn. 
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Claim 12 depends from Claim 10. Claim 30 depends from Claim 28, and Claim 82 
depends from Claim 72. Claim 12 is used as an example. Claims 30 and 82 include 
equivalent or similar limitations to those discussed below with respect to Claim 12. 

Claim 12 recites that at least part of the new authenticated rights locker access request 
is stored in a bookmark. The rejection has failed to cite any teaching or suggestion of storing 
of anything on a user device of Buhse or the need for such storing. The rejection finds a 
statement of a bookmark in Jiang and then uses a capability unrelated to Appellant's claim and 
unrelated to the bookmark of Jiang as a rationale for combining Jiang and Buhse. This is 
error. 

The motivation cited Col. 5, lines 38 to 44 of Jiang as providing the motivation to 
modify the bookmark of Jiang and put the modified bookmark in Buhse. This is error, as it 
fails to consider Jiang as a whole. Jiang stated: 

The preference profile contains users' preferences with regard to the services 
and devices. Preferences comprise device activation times, bookmarks, and 
notification preferences. 

Jiang, Col. 11, lines 59 to 62. 

The rejection failed to consider what Jiang taught about the location of the preference 
profile and the storage of that profile. Jiang taught: 

Finally, the profile manager 834 maintains the user's profiles as well as 
maintains the user's homepage based on those profiles. The user's homepage is the 
preferred method of the user's interaction between the WPM and the user. Preferably, 
the WPM allows the user to customize the user's homepage to fulfill the user's specific 
needs. 

The WPM maintains multiple profile schemas.... 

The profile schemas comprises, among others, the user profile, service profile, 
preference profile, device profile, usage profile, and logon profile. 

Jiang, Col. 11, lines 26 to 44. 

The profile manager of Jiang is part of a Portal Middleware Server as shown in Fig. 8 
of Jiang. WPM stands for Wireless Portal Middleware 210 of Jiang. Figs. 2 to 6 of Jiang 
show that the WPM is not on a user device. 

With respect to the ability to allow users to request user dependent data without the 
need for entering user identification, Jiang taught: 

Page 28 of 42 



Serial No. 10/687,459 

Notice of Appeal Entered: June 18, 2010 

Appeal Brief Filed: August 18, 2010 



The one-click data entry service enables a wireless device, which typically has 
limited input capabilities, to easily interact with services that require long, 
complicated, user-specific data entry. For instance, logon information required by 
some content providers allow users to register and customize the web site to suit the 
users' particular needs and desires. The logon information, however, is typically 
cumbersome to enter on an MS. The present invention, however, allows the user to 
interact with such services without the need to enter long strings of data by 
storing user-dependent data on the WPM . (All Emphasis Added.) 

Jiang, Col. 12, lines 57 to 67. 

Thus, Jiang does not teach or suggest in any way that the bookmark in the preference 
profile was used in allowing the user to interact with services without the need to enter long 
strings of data. Jiang does not teach that the bookmarks are stored on the user device. 

Jiang teaches that the bookmarks are in profiles that are stored on a Portal Middleware 
Server and the WPM. Jiang teaches that it is a capability of the WPM that reduces the data 
entry, and not any storage on a user device as posited in the rejection. The rejection takes the 
statements of Jiang out of context, misapplies the statements, and mischaracterizes the use of a 
bookmark by Jiang. 

Thus, when Jiang is taken as a whole as is required in an obviousness rejection, Jiang 
teaches that it undesirable to do the storage on the user device and instead shows that the 
storage is on portals. Accordingly, Jiang taken as a whole directly contradicts the assertions 
made by the selective extractions in the rejection. Jiang teaches away from both the 
motivation used in the rejection, and the storage location recited in Claim 12. Appellant notes 
that while the KSR decision may have modified the showing needed to combine prior art 
references, the KSR decision did not eliminate the requirement that each prior art reference be 
considered as a whole including parts that teach-away. 

Thus, the Examiner has failed to make a prima facie obviousness rejection and each of 
Claims 12, 30, and 82 distinguishes over the combination of references. Appellant 
respectfully requests withdrawal of the obviousness rejection of each of Claims 12, 30, and 
82. 



4. CLAIMS 15, 18, 33, 36, 85, and 88 ARE NOT ANTICIPATED BY BUHSE 

The rejection of Claims 15, 18, 33, 36, 85, and 88 as being anticipated by Buhse is in 
error for multiple reasons and should be withdrawn. As demonstrated more completely 
below, the rejection fails to comply with the multiple MPEP requirements for an anticipation 
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rejection. The rejection has failed to consider the plain meaning of the claims and has failed 
to consider all claims limitations. The rejection reduces express claim limitations to a gist and 
even then fails to demonstrate that the reference teaches the gist in the same level of detail and 
arranged as required by the claims. The rejection has failed to meet the MPEP requirements 
for an anticipation rejection and has not even made a valid obviousness rejection. 

With respect to Claims 15, 33, and 85, Claim 15 is used as an example. Claims 33 and 
85 include equivalent or similar limitations to those discussed below with respect to Claim 15. 

Each limitation in Claim 1 5 is performed by the same entity, a rights locker provider. 
The processes performed by the rights locker provider correspond to the processes performed 
on the user device in Claim 10. There is a correspondence between the number of 
authenticated access requests sent from the user device in Claim 10 and the number of 
requests received by the rights locker provider in Claim 15. Similarly, the items sent by the 
rights locker provider in Claim 15 are received by the user device in Claim 10. Accordingly, 
the comments with respect to the rejection of Claim 10 failing to provide a teaching of "a 
digital content specification and associated authenticated rights locker access request," "a new 
authenticated rights locker access requests," and "at least one of said one or more clickable 
links associated with an authenticated digital contend request," are directly applicable to 
Claim 15 and will not be repeated in detail. Since the rejection failed to establish that Buhse 
taught or suggested the access and content requests of Claim 10, the same comments apply to 
Claim 15 and are incorporated herein by reference. 

As in Claim 10, the access request in Claim 15 is not an access request in general, but 
rather a rights locker access request. However, the access is not just a rights locker access 
request but rather an authenticated rights locker access request. 

In addition, the authenticated rights locker access request was authenticated by the 
rights locker provider for the rights locker. As noted above and incorporated herein by 
reference, the Examiner incorrectly asserts in the advisory action that these limitations are not 
recited in Claim 15. Claim 15 includes the same language that was quoted above with respect 
to this limitation in Claim 10. See Claim 15, lines 5 to 8 and compare with Claim 10, lines 5 
to 7. Accordingly, the Examiner has demonstrated on the record that express claim limitations 
also were ignored with respect to Claim 15. 

The rejection of Claim 15 again starts with the third scenario of Buhse in Paragraphs 
[0064] to [0077] with respect to the first three limitations of Claim 15, but for the remainder 
of the claim limitations pulls in pieces of the first and second scenarios of Buhse. (See text in 
italics in FOA, Section 9, middle of pg. 9 to pg. 1 1). Recall that the first and second scenarios 
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of Buhse are described in Pargraphs [0047] to [0063]. Appellant has demonstrated above that 
such a selective extraction and recombination is inappropriate in an anticipation rejection and 
so will not yet again go through the same litany of errors, but again incorporate remarks with 
respect to these errors and Claim 10 herein. 

A consumer logging in using a promotion ID as in Bushe fails to teach receiving an 
access request that is already authenticated as recited in Claim 15. Further, authenticating a 
login fails to suggest or disclose validating a previously authenticated access request as recited 
in Claim 15. 

As noted above and incorporated herein by reference, Buhse fails to teach any 
authenticated request and to the extent that the rejection relies upon inherency such reliance is 
inappropriate as quoted above from the MPEP. Fig. 6B of Buhse shows the operations 
performed by the rights locker component of Buhse, which the rejection ignores and instead 
extracts parts of Buhse based on Appellant's claim language. 

These claims also recite that the rights locker provider creates a Web page with at least 
one link that includes an authenticated digital content request and sends the Web site and 
another authenticated rights locker access request to a user device. A consumer visiting a 
rights locker website as in the second scenario of Buhse fails to teach or suggest anything 
about what entity created the web page and fails to teach sending the web page with the 
recited access request to a user device. Moreover, the access cited in the second scenario 
occurs at the start of the scenario and not in the time sequence as recited in Claim 15. 

Further, the rejection has not cited any teaching of the links on the website other than 
"Rights Locker website to view the subscription plan (playlist) and selects tracks to 
download." Viewing a playlist and selecting tracks to download is different from what is 
recited in Claim 15, with " one or more clickable links that comprise an authenticated digital 
content request for use in accessing digital content stored by a digital content repository." 
There is no teaching or suggesting of the nature of links used in Buhse. Thus, the rejection 
has failed to demonstrate that Buhse teaches the invention in the same level of detail and 
arranged as required in the claim. 

Also, the rejection fails to cite with consistency any teaching that the second 
authenticated rights locker request is created by the rights locker provider, sent to the user 
device by the rights locker provider, and then received back by the rights locker provider from 
the user device as recited in Claim 15. Instead, the rejection jumps around in Buhse and cites 
to different things, which do not teach such operations with respect to a single authenticated 
rights locker access request, let alone the very specific second access request recited in the 
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claims. As previously noted the rejection takes pieces from different parts of a system and 
recombines those pieces according to Appellant's claim language and not any teaching in 
Buhse. 

Yet again, the explicit claim language has been reduced to a gist, but the MPEP 
requires that Buhse show the invention recited in these Claims in the same level of detail. 
Appellant respectfully requests reconsideration and withdrawal of the anticipation rejection of 
each of Claims 15, 33, and 85. 

Claims 18, 36, and 88 are patentable for at least the same reasons as Claims 15, 33, 
and 85. Appellant respectfully requests reconsideration and withdrawal of the anticipation 
rejection of each of Claims 18, 36, and 88. 

5. CLAIMS 16, 34, and 86 ARE PATENTABLE OVER BUHSE 

The rejection of Claims 16, 34, and 86 as being unpatentable over U.S. Patent 
Application Publication No. US 2004/0024652 Al (Buhse) in view of U.S. Patent No. 
7,136,63 1, hereinafter referred to as Jiang, is in error and should be withdrawn. 

Claim 16 depends from Claim 15. Claim 34 depends from Claim 23, and Claim 86 
depends from Claim 82. The above remarks with respect to Claims 12, 30, and 82 are directly 
applicable to these claims as the claims recite that "said second authenticated rights locker 
access request is for storage in a bookmark on said user device." The second authenticated 
rights locker access request of Claim 15 corresponds to the new authenticated rights locker 
access request of Claim 10. Thus, rather than repeat the remarks with respect to Claims 12, 20 
and 82 with the different names of the authenticated rights locker access request, the above 
remarks with respect of Claims 12, 20 and 82 are incorporated herein by reference. Appellant 
respectfully requests reconsideration and withdrawal of the anticipation rejection of each of 
Claims 16, 34, and 86. 

Claims 13, 17, 3 1, 35, 74 to 81, 83, and 87 also stand rejected as obvious. Each of 
these claims depends from a claim that is allowable and so is allowable for at least the same 
reasons. Thus, the allowability of each of Claims 13, 17, 31, 35, 74 to 81, 83, and 87 is not 
separately argued. 



CONCLUSION 

For the reasons above, all appealed claims, i.e., Claims 10 to 18, 28 to 36, and 72 to 
88, are allowable. Appellant respectfully requests the Board of Patent Appeals and 
Interferences to reverse the Examiner's rejections of these claims. 
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CLAIMS APPENDIX 



l.to9. (Cancelled) 



10. (Previously Presented) A method for digital content access control, comprising: 
determining, on a user device, a digital content specification and associated 

authenticated rights locker access request wherein said associated authenticated rights 
locker access request was authenticated by a right locker provider for the rights locker; 

sending, from said user device to said rights locker provider for the rights locker, 
said authenticated rights locker access request and said digital content specification; 

receiving, on said user device from said rights locker provider, a new 
authenticated rights locker access request for the rights locker and a Web page with one 
or more clickable links in response to said sending, at least one of said one or more 
clickable links associated with an authenticated digital content request; 

receiving, on said user device, an indication of a user selection of one of said one 
or more clickable links; 

sending, from said user device, said new authenticated rights locker access request 
and an indication of the right associated with said one of said one or more clickable links 
to said rights locker provider; and 

receiving, on said user device from a digital content repository, said digital content 
in response to said sending said new authenticated rights locker access request. 

11. (Previously Presented) The method of claim 10 wherein 

said method further comprises determining, on said user device, one or more 
delivery parameters, said one or more delivery parameters indicating where said digital 
content should be sent, a delivery mechanism, or both; and 

said sending said authenticated rights locker access request and said digital 
content specification further comprises sending said one or more delivery parameters. 



12. (Previously Presented) The method of claim 10, further comprising storing at 
least part of said new authenticated rights locker access request in a bookmark on said user 
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13. (Original) The method of claim 10 wherein said new authenticated rights locker 
access request is embedded in a Web cookie. 

14. (Previously Presented) The method of claim 10 wherein said new authenticated 
rights locker access request is encapsulated in a Hypertext Transfer Protocol (HTTP) 
Response message. 

15. (Previously Presented) A method for digital content access control, comprising: 
receiving, by a rights locker provider from a user device, a first authenticated 

rights locker access request and a digital content specification wherein said first 
authenticated rights locker access request was authenticated by said right locker provider 
for the rights locker; 

validating, by said rights locker provider, said first authenticated rights locker 
access request; and 

if said validating indicates said first authenticated rights locker access request is 

valid, 

creating, by said rights locker provider, a Web page with one or more 
clickable links that comprise an authenticated digital content request for use in 
accessing digital content stored by a digital content repository; 

sending, by said rights locker provider to said user device, a second 
authenticated rights locker access request for the rights locker and said Web page; 

receiving, by said rights locker provider from said user device, and validating, 
by said rights locker provider, said second authenticated rights locker access request 
for the rights locker; 

obtaining, by said rights locker provider, an authenticated digital content 
request if said second authenticated rights locker access request is valid; and 

sending, by said rights locker provider, said authenticated digital content 
request to a digital content repository. 

16. (Previously Presented) The method of claim 15 wherein at least part of said 
second authenticated rights locker access request is for storage in a bookmark on said user 
device. 
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17. (Original) The method of claim 15, further comprising embedding said second 
authenticated rights locker access request in a Web cookie before said sending. 

18. (Previously Presented) The method of claim 15, further comprising encapsulating 
said second authenticated rights locker access request in a Hypertext Transfer Protocol 
(HTTP) Response message before said sending. 

19. to 27. (Cancelled) 

28. (Previously Presented) A program storage device readable by a machine, 
embodying a program of instructions executable by the machine to perform a method for 
digital content access control, the method comprising: 

determining, on a user device, a digital content specification and associated 
authenticated rights locker access request wherein said associated authenticated rights 
locker access request was authenticated by a right locker provider for the rights locker; 

sending, from said user device to said rights locker provider for the rights locker, 
said authenticated rights locker access request and said digital content specification; 

receiving, on said user device from said rights locker provider, a new 
authenticated rights locker access request for the rights locker and a Web page with one 
or more clickable links in response to said sending, at least one of said one or more 
clickable links associated with an authenticated digital content request; 

receiving, on said user device, an indication of a user selection of one of said one 
or more clickable links; 

sending, from said user device, said new authenticated rights locker access request 
and an indication of the right associated with said one of said one or more clickable links 
to said rights locker provider; and 

receiving, on said user device from a digital content repository, said digital content 
in response to said sending said new authenticated rights locker access request. 

29. (Previously Presented) The program storage device of claim 28 wherein 
said method further comprises determining, on said user device, one or more 

delivery parameters, said one or more delivery parameters indicating where said digital 
content should be sent, a delivery mechanism, or both; and 
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said sending said authenticated rights locker access request and said digital 
content specification further comprises sending said one or more delivery parameters. 

30. (Previously Presented) The program storage device of claim 28, said method 
further comprising storing at least part of said new authenticated rights locker access request 
in a bookmark on said user device. 

3 1 . (Original) The program storage device of claim 28 wherein said new 
authenticated rights locker access request is embedded in a Web cookie. 

32. (Previously Presented) The program storage device of claim 28 wherein said new 
authenticated rights locker access request is encapsulated in a Hypertext Transfer Protocol 
(HTTP) Response message. 

33. (Previously Presented) A program storage device readable by a machine, 
embodying a program of instructions executable by the machine to perform a method for 
digital content access control, the method comprising: 

receiving, by a rights locker provider from a user device, a first authenticated 
rights locker access request and a digital content specification wherein said first 
authenticated rights locker access request was authenticated by said right locker provider 
for the rights locker; 

validating, by said rights locker provider, said first authenticated rights locker 
access request; and 

if said validating indicates said first authenticated rights locker access request is 

valid, 

creating, by said rights locker provider, a Web page with one or more 
clickable links that comprise an authenticated digital content request for use in 
accessing digital content stored by a digital content repository; 

sending, by said rights locker provider to said user device, a second 
authenticated rights locker access request for the rights locker and said Web page; 

receiving, by said rights locker provider from said user device, and validating, 
by said rights locker provider, said second authenticated rights locker access request 
for the rights locker; 
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obtaining, by said rights locker provider, an authenticated digital content 
request if said second authenticated rights locker access request is valid; and 

sending, by said rights locker provider, said authenticated digital content 
request to a digital content repository. 

34. (Previously Presented) The program storage device of claim 33 wherein at least 
part of said second authenticated rights locker access request is for storage in a bookmark on 
said user device. 

35. (Original) The program storage device of claim 33, further comprising embedding 
said second authenticated rights locker access request in a Web cookie before said sending. 

36. (Previously Presented) The program storage device of claim 33, further 
comprising encapsulating said second authenticated rights locker access request in a Hypertext 
Transfer Protocol (HTTP) Response message before said sending. 

37. to 45. (Cancelled) 
46. to 54. (Cancelled) 
55. to 71. (Cancelled) 

72. (Previously Presented) An apparatus for digital content access control, 
comprising: 

a memory for storing said digital content; and 
a processor configured to: 

determine, on a user device, a digital content specification and associated 
authenticated rights locker access request wherein said associated authenticated rights 
locker access request was authenticated by a right locker provider for the rights locker; 

send, from said user device to said rights locker provider for the rights locker, 
said authenticated rights locker access request and said digital content specification; 

receive, on said user device from said rights locker provider, a new 
authenticated rights locker access request for the rights locker and a Web page with 
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one or more clickable links in response to said sending, at least one of said one or 
more clickable links associated with an authenticated digital content request; 

receive, on said user device, an indication of a user selection of one of said one 
or more clickable links; 

send, from said user device, said new authenticated rights locker access request 
and an indication of the right associated with said one of said one or more clickable 
links to said rights locker provider; and 

receive, on said user device from a digital content repository, said digital 
content in response to said sending said new authenticated rights locker access request. 

73. (Previously Presented) The apparatus of claim 72 wherein said processor is 
further configured to: 

determine, on said user device, one or more delivery parameters, said one or more 
delivery parameters indicating where said digital content should be sent, a delivery 
mechanism, or both; and 

said sending said authenticated rights locker access request and said digital 
content specification further comprises sending said one or more delivery parameters. 

74. (Original) The apparatus of claim 72 wherein said apparatus comprises a smart 



75. (Original) The apparatus of claim 74 wherein said smart card comprises a Java 
Card™ technology-enabled smart card. 

76. (Original) The apparatus of claim 74 wherein said smart card comprises a CDMA 
(Code Division Multiple Access) technology-enabled smart card. 

77. (Original) The apparatus of claim 74 wherein said smart card comprises a SIM 
(Subscriber Identity Module) card. 



78. (Original) The apparatus of claim 74 wherein said smart card comprises a WIM 
(Wireless Interface Module). 
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79. (Original) The apparatus of claim 74 wherein said smart card comprises a USIM 
(Universal Subscriber Identity Module). 

80. (Original) The apparatus of claim 74 wherein said smart card comprises a UIM 
(User Identity Module). 

81. (Original) The apparatus of claim 74 wherein said smart card comprises a R-UIM 
(Removable User Identity Module). 

82. (Previously Presented) The apparatus of claim 72 wherein said processor is 
further configured to store at least part of said new authenticated rights locker access request 
in a bookmark on said user device. 

83. (Original) The apparatus of claim 72 wherein said new authenticated rights locker 
access request is embedded in a Web cookie. 

84. (Previously Presented) The apparatus of claim 72 wherein said new authenticated 
rights locker access request is encapsulated in a Hypertext Transfer Protocol (HTTP) 
Response message. 

85. (Previously Presented) An apparatus for digital content access control, 
comprising: 

a memory for storing one or more rights lockers that describe digital content 
access rights; and 

a processor configured to: 

receive, by a rights locker provider from a user device, a first authenticated 
rights locker access request and a digital content specification wherein said first 
authenticated rights locker access request was authenticated by said right locker 
provider for the rights locker; 

validate, by said rights locker provider, said first authenticated rights locker 
access request; and 

if said validating indicates said first authenticated rights locker access request 
is valid, 
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create, by said rights locker provider, a Web page with one or more 
clickable links that comprise an authenticated digital content request for use in 
accessing digital content stored by a digital content repository; 

send, by said rights locker provider to said user device, a second 
authenticated rights locker access request for the rights locker and said Web page; 

receive, by said rights locker provider from said user device, and 
validating, by said rights locker provider, said second authenticated rights locker 
access request for the rights locker; 

obtain, by said rights locker provider, an authenticated digital content 
request if said second authenticated rights locker access request is valid; and 

send, by said rights locker provider, said authenticated digital content 
request to a digital content repository. 

86. (Previously Presented) The apparatus of claim 85 wherein at least part of said 
second authenticated rights locker access request is for storage in a bookmark on said user 
device. 

87. (Original) The apparatus of claim 85 wherein said processor is further configured 
to embed said second authenticated rights locker access request in a Web cookie before said 
sending. 

88. (Previously Presented) The apparatus of claim 85 wherein said processor is 
further configured to encapsulate said second authenticated rights locker access request in a 
Hypertext Transfer Protocol (HTTP) Response message before said sending. 
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EVIDENCE APPENDIX 



None 
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